Generic transport networks, such as OTN (Optical Transport Network), SDH (Synchronous Digital Hierarchy) or SONET (Synchronous Optical NETwork) networks, are widely used for transmission of large data streams (e.g. a large number of telephone channels) between network elements in the telecommunications networks. These synchronous systems also allow the transmission of asynchronous signals, e.g. signals from a PDH (Plesiochronous Digital Hierarchy) with data rates of 140 Mbit/s, 34 Mbit/s or 2 Mbit/s, which may be mapped into e.g. a SDH system.
International standards prescribe how to place the individual bytes in the frames of the synchronous system. A detailed structure shows how this mapping is made. In the SDH system the payload data signals are placed together with overhead signals in so-called virtual containers, which may be higher order virtual containers, e.g. VC-4, or lower order virtual containers, e.g. VC-12 or VC-3.
SDH signals are a serial flow of logical 1's and 0's that may be subdivided into a sequence of bytes of 8 bits each. The signals are structured such that the transmitted bit flow may be subdivided into a plurality of channels for different applications. The basic structure of an SDH signal is a so-called Synchronous Transport Module at level 1 (STM-1), which may be considered as a frame having 9 rows and 270 bytes in each row. Of the 270 bytes the first nine bytes in each row are used for overhead and pointers, so that 261 bytes in each row constitute the transport capacity of the frame. An STM-1 frame is transmitted with a data rate of 155.52 Mbit/s. Corresponding STM frames of higher order (STM-N) also exist, and these are transmitted with corresponding higher data rates. As examples, STM-4, STM-16, STM-64 and STM-256 are specified.
The signals are transmitted one row at a time with the uppermost row first, and each row is transmitted from the left to the right. Each byte is transmitted with the most significant bit first. The transport capacity of the STM-1 frame, i.e. the 9 rows of 261 bytes each, constitutes a higher order virtual container VC-4. The payload capacity of a VC-4 is 149.76 Mbit/s. For the lower order virtual containers, which may be mapped into the VC-4, the payload capacity is 49.536 Mbit/s for the VC-3 and 2.176 Mbit/s for the VC-12.
These bit rates are well suited for transporting e.g. PDH signals, which, as mentioned, the SDH system is frequently used for. In that case a VC-4 may e.g. contain a PDH channel of 140 Mbit/s, or it may be subdivided into a plurality of smaller virtual containers. It may e.g. contain 3 VC-3s each transporting a PDH channel of 34 Mbit/s or 63 VC-12s each transporting a PDH channel of 2 Mbit/s.
However, many services or data types require bit rates, which cannot utilize the possible bit rates of the virtual containers effectively. As an example, a data rate of 10 Mbit/s is required, when Ethernet data are transmitted through an SDH network. The smallest virtual container that will accommodate a 10 Mbit/s payload is a VC-3, which means that the transport efficiency is as low as 20%. Other data types with poor transport efficiencies in SDH are Fast Ethernet, ESCON, Fibre Channel and Gigabit Ethernet. The transport efficiency for such data types may be improved by concatenating virtual containers. Two types of concatenation exist, contiguous concatenation and virtual concatenation.
Contiguous concatenation is used when payloads greater than the capacity of e.g. a VC-4 is to be transmitted. In that case several containers may be locked to each other so that the concatenated containers are transmitted together through the network, in which the relevant network elements must be set up by the management system to handle the concatenated containers. As examples of contiguous concatenated containers, VC-4-4c, VC-4-16c and VC-4-64c can be mentioned. These containers can be transmitted in STM-4, STM-16 and STM-64 frames.
By virtual concatenation, the payload may be divided between a number of virtual containers in a more flexible way. For instance, Ethernet data of 10 Mbit/s may be transmitted in 5 VC-12 containers. Although the 5 containers constitute a Virtual Concatenation Group (VCG), they are transmitted as individual containers through the network, so that by virtual concatenation, there are no special requirements on the existing network elements or strict routing constraints for the network. The virtual containers of a VCG are also called the members of the group. In the receiving network element the virtual containers of the VCG can be recognized on their overhead, and a differential delay caused by difference in (optical) path length can be compensated, so that the data of the 5 containers can be combined again. Thus by means of virtual concatenation the transport efficiency is improved considerably, and network operators can implement connections that are more appropriate for the above-mentioned services by providing a much more flexible bandwidth granularity. Further, virtual concatenation is transparent to intermediate network elements, which means that it can be implemented without the need for any upgrade of the existing network elements.
Many of these services have variable requirements for bandwidth over time, and thus there is a need to be able to increase or decrease the capacity of a VCG link by adding or removing members from the group in order to meet the bandwidth needs of the application. The capacity of the VCG should be increased or decreased hitless, where a hit is a situation in which loss of data occurs. Further, in case a failure is experienced in the link for a member in the network, the transmission capacity needs to be decreased to avoid that the whole VCG fails. These functions can be handled by the Link Capacity Adjustment Scheme (LCAS) for virtual concatenated signals as specified by the ITU-T Recommendation G.7042/Y.1305. This Recommendation defines the required states at the source and at the sink side of the link as well as the control information exchanged between both the source and the sink side of the link to enable the flexible resizing of the virtual concatenated signal.
In LCAS, synchronization of changes in the capacity of the transmitter (source side) and the receiver (sink side) is achieved by control packets. Each control packet describes the state of the link during the next control packet. Changes are sent in advance so that the receiver can switch to the new configuration at a predefined time. The control packet consists of fields dedicated to specific functions. Control packets contain information sent from source to sink, i.e. the forward direction, and from sink to source, i.e. the return direction. The information in the forward direction comprises a control field providing commands indicating the status of the individual members of the group. The information in the return direction comprises an MST (Member Status) field, which reports the member status from sink to source with the two possible states OK and FAIL.
The network elements of a link are controlled by one or more management systems. The management system can instruct the end network elements, i.e. source or sink side, to add members to or remove members from the group. This is done by sending management messages.
The three main functions of the LCAS is to increase the VCG capacity by the addition of members, to decrease the VCG capacity by temporary removal of members due to a failure, and to decrease the VCG capacity by permanent removal of members due to a change in the bandwidth needs of the application.
When members are removed permanently to adapt the VCG capacity to the bandwidth needs of the application, three operations are required, i.e. the VCG size is reduced at the source end, the physical connection is removed between the source and the sink end, and the VCG size is reduced at the sink end. The LCAS Recommendation states that although a VCG capacity decrease can be initiated at either end by sending a management message from the management system, a planned VCG capacity reduction will only be hitless when the decrease is initiated at the source, i.e. the VCG size is first reduced at the source end. In this case a command indicating that the member is to be removed is sent from the source, and the payload data are removed from the following frames. If, on the other hand, a permanent removal of an active member is initiated at the sink side, this will result in a hit to the reconstructed data, because the source end will continue to send payload data on this member until it finds out that the member can not be used any longer.
For a unidirectional link this is not a problem. The network and element management system just has to ensure that the VCG capacity decrease is initiated at the source side. However, in practice, transmission networks are typically operated and configured bidirectionally, so that at least for most links payload data are transmitted in both directions. This means that a given network element will be the source for transmission in one direction and the sink for transmission in the other direction. If the network and element management system instructs this element to decrease the VCG capacity, this can only be done in a hitless manner for the transmission direction in which that element is the source. In the other direction the element would have to wait for the other end to reduce the VCG size before it can reduce the VCG size itself, if traffic hits shall be avoided. This is not always possible. It is especially a problem when the two network elements connected by the link belong to different operator domains, or if they are for any other reason managed by different network and element management systems.